home *** CD-ROM | disk | FTP | other *** search
/ Risc World 5 / Risc World 5.iso / SOFTWARE / Issue6 / VICE / VICE.ZIP / doc / vice_11 < prev    next >
Encoding:
Text File  |  2005-01-25  |  17.6 KB  |  618 lines
  1. <HTML>
  2. <HEAD>
  3. <!-- This HTML file has been created by texi2html 1.52
  4.      from ../vice.texi on 23 January 2005 -->
  5.  
  6. <TITLE>VICE Manual - 11  The emulator file formats</TITLE>
  7. </HEAD>
  8. <BODY>
  9. Go to the <A HREF="vice_1.html">first</A>, <A HREF="vice_10.html">previous</A>, <A HREF="vice_12.html">next</A>, <A HREF="vice_16.html">last</A> section, <A HREF="vice_toc.html">table of contents</A>.
  10. <P><HR><P>
  11.  
  12.  
  13. <H1><A NAME="SEC152" HREF="vice_toc.html#TOC152">11  The emulator file formats</A></H1>
  14.  
  15. <P>
  16. This chapter gives a technical description of the various files
  17. supported by the emulators.
  18.  
  19. </P>
  20.  
  21.  
  22.  
  23. <H2><A NAME="SEC153" HREF="vice_toc.html#TOC153">11.1  The T64 tape image format</A></H2>
  24.  
  25. <P>
  26. (This section was taken from the C64S distribution.)
  27.  
  28. </P>
  29. <P>
  30. The <CODE>T64</CODE> File Structure was developed by Miha Peternel for use in
  31. the C64S emulator.  It is easy to use and allows future extensions.
  32.  
  33. </P>
  34.  
  35.  
  36.  
  37. <H3><A NAME="SEC154" HREF="vice_toc.html#TOC154">11.1.1  T64 File structure</A></H3>
  38.  
  39. <TABLE BORDER>
  40.  
  41. <TR><TD><B>Offset</B></TD>
  42.  
  43. <TD><B>Size</B></TD>
  44. <TD><B>Description</B></TD>
  45. </TR>
  46. <TR><TD>0</TD>
  47.  
  48. <TD>64</TD>
  49. <TD>tape record</TD>
  50. </TR>
  51. <TR><TD>64</TD>
  52.  
  53. <TD>32*n</TD>
  54. <TD>file records for n directory entries</TD>
  55. </TR>
  56. <TR><TD>64+32*n</TD>
  57.  
  58. <TD>varies</TD>
  59. <TD>binary contents of the files</TD>
  60. </TR></TABLE>
  61.  
  62.  
  63.  
  64. <H3><A NAME="SEC155" HREF="vice_toc.html#TOC155">11.1.2  Tape Record</A></H3>
  65.  
  66. <TABLE BORDER>
  67.  
  68. <TR><TD><B>Offset</B></TD>
  69.  
  70. <TD><B>Size</B></TD>
  71. <TD><B>Description</B></TD>
  72. </TR>
  73. <TR><TD>0</TD>
  74.  
  75. <TD>32</TD>
  76. <TD>DOS tape description + EOF (for type)</TD>
  77. </TR>
  78. <TR><TD>32</TD>
  79.  
  80. <TD>2</TD>
  81. <TD>tape version ($0200)</TD>
  82. </TR>
  83. <TR><TD>34</TD>
  84.  
  85. <TD>2</TD>
  86. <TD>number of directory entries</TD>
  87. </TR>
  88. <TR><TD>36</TD>
  89.  
  90. <TD>2</TD>
  91. <TD>number of used entries (can be 0 in my loader)</TD>
  92. </TR>
  93. <TR><TD>38</TD>
  94.  
  95. <TD>2</TD>
  96. <TD>free</TD>
  97. </TR>
  98. <TR><TD>40</TD>
  99.  
  100. <TD>24</TD>
  101. <TD>user description as displayed in tape menu</TD>
  102. </TR></TABLE>
  103.  
  104.  
  105.  
  106. <H3><A NAME="SEC156" HREF="vice_toc.html#TOC156">11.1.3  File record</A></H3>
  107.  
  108. <TABLE BORDER>
  109.  
  110. <TR><TD><B>Offset</B></TD>
  111.  
  112. <TD><B>Size</B></TD>
  113. <TD><B>Description</B></TD>
  114. </TR>
  115. <TR><TD>0</TD>
  116.  
  117. <TD>1</TD>
  118. <TD>entry type (see below)</TD>
  119. </TR>
  120. <TR><TD>1</TD>
  121.  
  122. <TD>1</TD>
  123. <TD>C64 file type</TD>
  124. </TR>
  125. <TR><TD>2</TD>
  126.  
  127. <TD>2</TD>
  128. <TD>start address</TD>
  129. </TR>
  130. <TR><TD>4</TD>
  131.  
  132. <TD>2</TD>
  133. <TD>end address</TD>
  134. </TR>
  135. <TR><TD>6</TD>
  136.  
  137. <TD>2</TD>
  138. <TD>free</TD>
  139. </TR>
  140. <TR><TD>8</TD>
  141.  
  142. <TD>4</TD>
  143. <TD>offset of file contents start within T64 file</TD>
  144. </TR>
  145. <TR><TD>12</TD>
  146.  
  147. <TD>4</TD>
  148. <TD>free</TD>
  149. </TR>
  150. <TR><TD>16</TD>
  151.  
  152. <TD>16</TD>
  153. <TD>C64 file name</TD>
  154. </TR></TABLE>
  155.  
  156. <P>
  157. Valid entry types are:
  158.  
  159. </P>
  160. <TABLE BORDER>
  161.  
  162. <TR><TD><B>Code</B></TD>
  163.  
  164. <TD><B>Explanation</B></TD>
  165. </TR>
  166. <TR><TD><CODE>0</CODE></TD>
  167.  
  168. <TD>free entry</TD>
  169. </TR>
  170. <TR><TD><CODE>1</CODE></TD>
  171.  
  172. <TD>normal tape file</TD>
  173. </TR>
  174. <TR><TD><CODE>2</CODE></TD>
  175.  
  176. <TD>tape file with header: header is saved just before file data</TD>
  177. </TR>
  178. <TR><TD><CODE>3</CODE></TD>
  179.  
  180. <TD>memory snapshot v0.9, uncompressed</TD>
  181. </TR>
  182. <TR><TD><CODE>4</CODE></TD>
  183.  
  184. <TD>tape block</TD>
  185. </TR>
  186. <TR><TD><CODE>5</CODE></TD>
  187.  
  188. <TD>digitized stream</TD>
  189. </TR>
  190. <TR><TD><CODE>6</CODE> ... <CODE>255</CODE></TD>
  191.  
  192. <TD>reserved</TD>
  193. </TR></TABLE>
  194.  
  195. <P>
  196. Notes:
  197.  
  198. </P>
  199.  
  200. <UL>
  201. <LI>VICE only supports file type <CODE>1</CODE>.
  202.  
  203. <LI>Types <CODE>3</CODE>, <CODE>4</CODE> and <CODE>5</CODE> are subject to change (and
  204.  
  205. are rarely  used).
  206. </UL>
  207.  
  208.  
  209.  
  210. <H2><A NAME="SEC157" HREF="vice_toc.html#TOC157">11.2  The G64 GCR-encoded disk image format</A></H2>
  211.  
  212. <P>
  213. (This section was contributed by Peter Schepers and slightly edited by
  214. Ettore Perazzoli.)
  215.  
  216. </P>
  217. <P>
  218. This format was defined in 1998 as a cooperative effort between several
  219. emulator people, mainly Per Håkan Sundell, author of the CCS64 C64
  220. emulator, Andreas Boose of the VICE CBM emulator team and Joe
  221. Forster/STA, the author of Star Commander.  It was the first real public
  222. attempt to create a format for the emulator community which removed
  223. almost all of the drawbacks of the other existing image formats, namely
  224. <CODE>D64</CODE>.
  225.  
  226. </P>
  227. <P>
  228. The intention behind <CODE>G64</CODE> is not to replace the widely used
  229. <CODE>D64</CODE> format, as <CODE>D64</CODE> works fine with the vast majority of
  230. disks in existence.  It is intended for those small percentage of
  231. programs which demand to work with the 1541 drive in a non-standard way,
  232. such as reading or writing data in a custom format.  The best example is
  233. with speeder software such as Action Cartridge in Warp Save mode or
  234. Vorpal which write track/sector data in another format other than
  235. standard GCR.  The other obvious example is copy-protected software
  236. which looks for some specific data on a track, like the disk ID, which
  237. is not stored in a standard <CODE>D64</CODE> image.
  238.  
  239. </P>
  240. <P>
  241. <CODE>G64</CODE> has a deceptively simply layout for what it is capable of
  242. doing.  We have a signature, version byte, some predefined size values,
  243. and a series of offsets to the track data and speed zones.  It is what's
  244. contained in the track data areas and speed zones which is really at the
  245. heart of this format.
  246.  
  247. </P>
  248. <P>
  249. Each track entry in simply the raw stream of GCR data, just what a read
  250. head would see when a diskette is rotating past it.  How the data gets
  251. interpreted is up to the program trying to access the disk.  Because the
  252. data is stored in such a low-level manner, just about anything can be
  253. done.  Most of the time I would suspect the data in the track would be
  254. standard sectors, with SYNC, GAP, header, data and checksums.  The
  255. arrangement of the data when it is in a standard GCR sector layout is
  256. beyond the scope of this document.
  257.  
  258. </P>
  259. <P>
  260. Since it is a flexible format in both track count and track byte size,
  261. there is no "standard" file size.  However, given a few constants like
  262. 42 tracks and halftracks, a track size of 7928 bytes and no speed offset
  263. entries, the typical file size will a minimum of 333744 bytes.
  264.  
  265. </P>
  266. <P>
  267. Below is a dump of the header, broken down into its various parts.
  268. After that will be an explanation of the track offset and speed zone
  269. offset areas, as they demand much more explanation.
  270.  
  271. </P>
  272.  
  273. <PRE>
  274. Addr  00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
  275. ----  -----------------------------------------------
  276. 0000: 47 43 52 2D 31 35 34 31 00 54 F8 1E .. .. .. ..
  277. </PRE>
  278.  
  279. <TABLE BORDER>
  280.  
  281. <TR><TD><B>Offset</B></TD>
  282.  
  283. <TD><B>Description</B></TD>
  284. </TR>
  285. <TR><TD>$0000-0007</TD>
  286.  
  287. <TD>File signature (<CODE>GCR-1541</CODE>)</TD>
  288. </TR>
  289. <TR><TD>$0008</TD>
  290.  
  291. <TD><CODE>G64</CODE> version (presently only $00 defined)</TD>
  292. </TR>
  293. <TR><TD>$0009</TD>
  294.  
  295. <TD>Number of tracks in image (usually $54, decimal 84)</TD>
  296. </TR>
  297. <TR><TD>$000A-000B</TD>
  298.  
  299. <TD>Size of each stored track in bytes (usually 7928, or $1EF8) in LO/HI format.</TD>
  300. </TR></TABLE>
  301.  
  302. <P>
  303. An obvious question here is "why are there 84 tracks defined when a
  304. normal <CODE>D64</CODE> disk only has 35 tracks?"  Well, by definition, this
  305. image includes all half-tracks, so there are actually 42 tracks and 42
  306. half tracks.  The 1541 stepper motor can access up to 42 tracks and the
  307. in-between half-tracks.  Even though using more than 35 tracks is not
  308. typical, it was important to define this format from the start with what
  309. the 1541 is capable of doing, and not just what it typically does.
  310.  
  311. </P>
  312. <P>
  313. At first, the defined track size value of 7928 bytes may seem to be
  314. arbitrary, but it is not.  It is determined by the fastest write speed
  315. possible (speed zone 0), coupled with the average rotation speed of the
  316. disk (300 rpm).  After some math, the answer that actually comes up is
  317. 7692 bytes.  Why the discrepency between the actual size of 7692 and the
  318. defined size of 7928? Simply put, not all drives rotate at 300 rpm.
  319. Some can be faster or slower, so a upper safety margin of +3% was built
  320. added, in case some disks rotate slower and can write more data.  After
  321. applying this safety factor, and some rounding-up, 7928 bytes per track
  322. was arrived at.
  323.  
  324. </P>
  325. <P>
  326. Also note that this upper limit of 7928 bytes per track really only
  327. applies to 1541 and compatible disks.  If this format were applied to
  328. another disk type like the SFD1001, this value would be higher.
  329.  
  330. </P>
  331. <P>
  332. Below is a dump of the first section of a <CODE>G64</CODE> file, showing the offsets
  333. to the data portion for each track and half-track entry. Following that
  334. is a dump of the speed zone offsets.
  335.  
  336. </P>
  337.  
  338. <PRE>
  339. Addr  00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
  340. ----  -----------------------------------------------
  341. 0000: .. .. .. .. .. .. .. .. .. .. .. .. AC 02 00 00
  342. 0010: 00 00 00 00 A6 21 00 00 00 00 00 00 A0 40 00 00
  343. 0020: 00 00 00 00 9A 5F 00 00 00 00 00 00 94 7E 00 00
  344. 0030: 00 00 00 00 8E 9D 00 00 00 00 00 00 88 BC 00 00
  345. 0040: 00 00 00 00 82 DB 00 00 00 00 00 00 7C FA 00 00
  346. 0050: 00 00 00 00 76 19 01 00 00 00 00 00 70 38 01 00
  347. 0060: 00 00 00 00 6A 57 01 00 00 00 00 00 64 76 01 00
  348. 0070: 00 00 00 00 5E 95 01 00 00 00 00 00 58 B4 01 00
  349. 0080: 00 00 00 00 52 D3 01 00 00 00 00 00 4C F2 01 00
  350. 0090: 00 00 00 00 46 11 02 00 00 00 00 00 40 30 02 00
  351. 00A0: 00 00 00 00 3A 4F 02 00 00 00 00 00 34 6E 02 00
  352. 00B0: 00 00 00 00 2E 8D 02 00 00 00 00 00 28 AC 02 00
  353. 00C0: 00 00 00 00 22 CB 02 00 00 00 00 00 1C EA 02 00
  354. 00D0: 00 00 00 00 16 09 03 00 00 00 00 00 10 28 03 00
  355. 00E0: 00 00 00 00 0A 47 03 00 00 00 00 00 04 66 03 00
  356. 00F0: 00 00 00 00 FE 84 03 00 00 00 00 00 F8 A3 03 00
  357. 0100: 00 00 00 00 F2 C2 03 00 00 00 00 00 EC E1 03 00
  358. 0110: 00 00 00 00 E6 00 04 00 00 00 00 00 E0 1F 04 00
  359. 0120: 00 00 00 00 DA 3E 04 00 00 00 00 00 D4 5D 04 00
  360. 0130: 00 00 00 00 CE 7C 04 00 00 00 00 00 C8 9B 04 00
  361. 0140: 00 00 00 00 C2 BA 04 00 00 00 00 00 BC D9 04 00
  362. 0150: 00 00 00 00 B6 F8 04 00 00 00 00 00 .. .. .. ..
  363. </PRE>
  364.  
  365. <TABLE BORDER>
  366.  
  367. <TR><TD><B>Offset</B></TD>
  368.  
  369. <TD><B>Description</B></TD>
  370. </TR>
  371. <TR><TD>$000C-000F</TD>
  372.  
  373. <TD>Offset to stored track 1.0 ($000002AC, in LO/HI format, see below for more)</TD>
  374. </TR>
  375. <TR><TD>$0010-0013</TD>
  376.  
  377. <TD>Offset to stored track 1.5 ($00000000)</TD>
  378. </TR>
  379. <TR><TD>$0014-0017</TD>
  380.  
  381. <TD>Offset to stored track 2.0 ($000021A6)</TD>
  382. </TR>
  383. <TR><TD>...</TD>
  384.  
  385. </TR>
  386. <TR><TD>$0154-0157</TD>
  387.  
  388. <TD>Offset to stored track 42.0 ($0004F8B6)</TD>
  389. </TR>
  390. <TR><TD>$0158-015B</TD>
  391.  
  392. <TD>Offset to stored track 42.5 ($00000000)</TD>
  393. </TR></TABLE>
  394.  
  395.  
  396. <PRE>
  397.       00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
  398.       -----------------------------------------------
  399. 0150: .. .. .. .. .. .. .. .. .. .. .. .. 03 00 00 00
  400. 0160: 00 00 00 00 03 00 00 00 00 00 00 00 03 00 00 00
  401. 0170: 00 00 00 00 03 00 00 00 00 00 00 00 03 00 00 00
  402. 0180: 00 00 00 00 03 00 00 00 00 00 00 00 03 00 00 00
  403. 0190: 00 00 00 00 03 00 00 00 00 00 00 00 03 00 00 00
  404. 01A0: 00 00 00 00 03 00 00 00 00 00 00 00 03 00 00 00
  405. 01B0: 00 00 00 00 03 00 00 00 00 00 00 00 03 00 00 00
  406. 01C0: 00 00 00 00 03 00 00 00 00 00 00 00 03 00 00 00
  407. 01D0: 00 00 00 00 03 00 00 00 00 00 00 00 03 00 00 00
  408. 01E0: 00 00 00 00 02 00 00 00 00 00 00 00 02 00 00 00
  409. 01F0: 00 00 00 00 02 00 00 00 00 00 00 00 02 00 00 00
  410. 0200: 00 00 00 00 02 00 00 00 00 00 00 00 02 00 00 00
  411. 0210: 00 00 00 00 02 00 00 00 00 00 00 00 01 00 00 00
  412. 0220: 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00
  413. 0230: 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00
  414. 0240: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
  415. 0250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  416. 0260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  417. 0270: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  418. 0280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  419. 0290: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  420. 02A0: 00 00 00 00 00 00 00 00 00 00 00 00 .. .. .. ..
  421. </PRE>
  422.  
  423. <TABLE BORDER>
  424.  
  425. <TR><TD><B>Offset</B></TD>
  426.  
  427. <TD><B>Description</B></TD>
  428. </TR>
  429. <TR><TD>$015C-015F</TD>
  430.  
  431. <TD>Speed zone entry for track 1 ($03, in LO/HI  format, see below for more)</TD>
  432. </TR>
  433. <TR><TD>$0160-0163</TD>
  434.  
  435. <TD>Speed zone entry for track 1.5 ($03)</TD>
  436. </TR>
  437. <TR><TD>...</TD>
  438.  
  439. </TR>
  440. <TR><TD>$02A4-02A7</TD>
  441.  
  442. <TD>Speed zone entry for track 42 ($00)</TD>
  443. </TR>
  444. <TR><TD>$02A8-02AB</TD>
  445.  
  446. <TD>Speed zone entry for track 42.5 ($00)</TD>
  447. </TR></TABLE>
  448.  
  449. <P>
  450. Starting here at $02AC is the first track entry (from above, it is the
  451. first entry for track 1.0)
  452.  
  453. </P>
  454. <P>
  455. The track offsets (from above) require some explanation.  When one is
  456. set to all 0's, no track data exists for this entry.  If there is a
  457. value, it is an absolute reference into the file (starting from the
  458. beginning of the file).  From the track 1.0 entry we see it is set for
  459. $000002AC.  Going to that file offset, here is what we see...
  460.  
  461. </P>
  462.  
  463. <PRE>
  464.       00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
  465.       -----------------------------------------------
  466. 02A0: .. .. .. .. .. .. .. .. .. .. .. .. 0C 1E FF FF
  467. 02B0: FF FF FF 52 54 B5 29 4B 7A 5E 95 55 55 55 55 55
  468. 02C0: 55 55 55 55 55 55 FF FF FF FF FF 55 D4 A5 29 4A
  469. 02D0: 52 94 A5 29 4A 52 94 A5 29 4A 52 94 A5 29 4A 52
  470. </PRE>
  471.  
  472. <TABLE BORDER>
  473.  
  474. <TR><TD><B>Offset</B></TD>
  475.  
  476. <TD><B>Description</B></TD>
  477. </TR>
  478. <TR><TD>$02AC-02AD</TD>
  479.  
  480. <TD>Actual size of stored track (7692 or $1E0C, in LO/HI format)</TD>
  481. </TR>
  482. <TR><TD>$02AE-02AE+$1E0C</TD>
  483.  
  484. <TD>Track data</TD>
  485. </TR></TABLE>
  486.  
  487. <P>
  488. Following the track data is filler bytes.  In this case, there are 368
  489. bytes of unused space.  This space can contain anything, but for the
  490. sake of those wishing to compress these images for storage, they should
  491. all be set to the same value.  In the sample I used, these are all set
  492. to $FF.
  493.  
  494. </P>
  495. <P>
  496. Below is a dump of the end of the track 1.0 data area.  Note the actual
  497. track data ends at address $20B9, with the rest of the block being
  498. unused, and set to $FF.
  499.  
  500. </P>
  501.  
  502. <PRE>
  503.       00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
  504.       -----------------------------------------------
  505. 1FE0: 52 94 A5 29 4A 52 94 A5 29 4A 52 94 A5 29 4A 52
  506. 1FF0: 94 A5 29 4A 52 94 A5 29 4A 52 94 A5 29 4A 52 94
  507. 2000: A5 29 4A 52 94 A5 29 4A 52 94 A5 29 4A 52 94 A5
  508. 2010: 29 4A 52 94 A5 29 4A 52 94 A5 29 4A 52 94 A5 29
  509. 2020: 4A 52 94 A5 29 4A 52 94 A5 29 4A 52 94 A5 29 4A
  510. 2030: 55 55 55 55 55 55 FF FF FF FF FF FF FF FF FF FF
  511. 2040: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
  512. 2050: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
  513. 2060: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
  514. 2070: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
  515. 2080: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
  516. 2090: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
  517. 20A0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
  518. 20B0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
  519. 20C0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
  520. 20D0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
  521. 20E0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
  522. 20F0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
  523. 2100: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
  524. 2110: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
  525. 2120: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
  526. 2130: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
  527. 2140: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
  528. 2150: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
  529. 2160: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
  530. 2170: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
  531. 2180: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
  532. 2190: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
  533. 21A0: FF FF FF FF FF FF .. .. .. .. .. .. .. .. .. ..
  534. </PRE>
  535.  
  536. <P>
  537. The speed offset entries can be a little more complex. The 1541 has four
  538. speed zones defined, which means the drive can write data at four
  539. distinct speeds.  On a normal 1541 disk, these zones are as follows:
  540.  
  541. </P>
  542. <TABLE BORDER>
  543.  
  544. <TR><TD><B>Track Range</B></TD>
  545.  
  546. <TD><B>Speed Zone</B></TD>
  547. </TR>
  548. <TR><TD>1-17</TD>
  549.  
  550. <TD>3  (highest writing speed)</TD>
  551. </TR>
  552. <TR><TD>18-24</TD>
  553.  
  554. <TD>2</TD>
  555. </TR>
  556. <TR><TD>25-30</TD>
  557.  
  558. <TD>1</TD>
  559. </TR>
  560. <TR><TD>31 and up</TD>
  561.  
  562. <TD>0 (lowest writing speed)</TD>
  563. </TR></TABLE>
  564.  
  565. <P>
  566. Note that you can, through custom programming of the 1541, change the
  567. speed zone of any track to something different (change the 3 to a 0) and
  568. write data differently.  From the dump of the speed offset entries
  569. above, we see that all the entries are in the range of 0-3. If any entry
  570. is less than 4, this is not considered a speed offset but defines the
  571. whole track to be recorded at that one speed.
  572.  
  573. </P>
  574. <P>
  575. In the example I had, there were no offsets defined, so no speed zone
  576. dump can be shown.  However, I can define what should be there.  You
  577. will have a block of data, 1982 bytes long.  Each byte is encoded to
  578. represent the speed of 4 bytes in the track offset area, and is broken
  579. down as follows:
  580.  
  581. </P>
  582.  
  583. <PRE>
  584. Speed entry $FF:  in binary %11111111
  585.                              |'|'|'|'
  586.                              | | | |
  587.                              | | | +- 4'th byte speed (binary 11, 3 dec)
  588.                              | | +--- 3'rd byte speed (binary 11, 3 dec)
  589.                              | +----- 2'nd byte speed (binary 11, 3 dec)
  590.                              +------- 1'st byte speed (binary 11, 3 dec)
  591. </PRE>
  592.  
  593. <P>
  594. It was very smart thinking to allow for two speed zone settings, one in
  595. the offset block and another defining the speed on a per-byte basis.  If
  596. you are working with a normal disk, where each track is one constant
  597. speed, then you don't need the extra blocks of information hanging
  598. around the image, wasting space.
  599.  
  600. </P>
  601. <P>
  602. What may not be obvious is the flexibility of this format to add tracks
  603. and speed offset zones at will.  If a program decides to write a track
  604. out with varying speeds, and no speed offset exist, a new block will be
  605. created by appending it to the end of the image, and the offset pointer
  606. for that track set to point to the new block.  If a track has no offset
  607. yet, meaning it doesn't exist (like a half-track), and one needs to be
  608. added, the same procedure applies.  The location of the actual track or
  609. speed zone data is not important, meaning they do not have to be in any
  610. particular order since they are all referenced by the offsets at the
  611. beginning of the image.
  612.  
  613. </P>
  614. <P><HR><P>
  615. Go to the <A HREF="vice_1.html">first</A>, <A HREF="vice_10.html">previous</A>, <A HREF="vice_12.html">next</A>, <A HREF="vice_16.html">last</A> section, <A HREF="vice_toc.html">table of contents</A>.
  616. </BODY>
  617. </HTML>
  618.